MBSE와 디지털 트랜스포메이션

MBSE와 디지털 트랜스포메이션

2025-12-04, G30DR

1. 서론: 시스템 엔지니어링의 위기와 패러다임의 전환

현대 산업 기술의 복잡성은 기하급수적으로 증가하고 있다. 항공우주, 방위산업, 자동차, 의료 기기 등 안전 필수(Safety-Critical) 시스템을 다루는 산업군은 하드웨어와 소프트웨어, 그리고 네트워크가 얽힌 거대한 복합 체계(System of Systems)로 진화했다. 이러한 환경에서 전통적인 문서 중심 시스템 엔지니어링(Document-Centric Systems Engineering) 접근 방식은 한계에 봉착했다. 수천 페이지에 달하는 사양서와 설계 문서는 정보의 파편화를 초래했고, 설계 변경에 따른 영향 분석(Impact Analysis)을 불가능하게 만들었으며, 이는 결국 막대한 비용 초과와 일정 지연, 심지어 치명적인 시스템 결함으로 이어졌다.1

특히 소프트웨어의 비중이 폭발적으로 증가함에 따라, 시스템의 무결성을 보장하기 위한 검증(Verification) 및 확인(Validation)의 난이도는 극에 달하고 있다. 2022년 CISQ 보고서에 따르면, 미국 내 저품질 소프트웨어로 인한 비용은 약 2조 4,100억 달러에 달하며, 이는 개발 단계에서의 결함 발견 실패가 경제적으로 얼마나 큰 손실을 초래하는지를 증명한다.4 이러한 배경 속에서 모델 기반 시스템 엔지니어링(MBSE, Model-Based Systems Engineering)은 단순한 도구의 도입을 넘어, 엔지니어링 데이터의 디지털화를 통해 시스템 수명 주기 전반을 혁신하는 디지털 트랜스포메이션의 핵심 엔진으로 부상했다.

본 보고서는 MBSE가 주도하는 엔지니어링 프로세스의 변화를 심층적으로 분석한다. 특히 전통적인 V-모델이 디지털 환경에서 어떻게 진화하고 있는지, 가상 검증(Virtual Validation)과 시프트 레프트(Shift-Left) 전략이 어떻게 비용 효율성과 품질을 동시에 달성하는지, 그리고 항공우주 분야의 엄격한 표준인 DO-178C와 DO-331이 이러한 변화를 어떻게 수용하고 규제하는지를 면밀히 고찰한다. 나아가 생성형 AI(Generative AI)와 디지털 트윈(Digital Twin) 기술이 융합된 MBSE 2.0의 미래상을 제시한다.

2. MBSE의 본질과 디지털 스레드(Digital Thread)의 구축

2.1 문서 중심에서 모델 중심으로: 진실의 단일 공급원(SSOT)

MBSE의 핵심 철학은 시스템 정보를 정적인 ’문서’가 아닌 동적인 ’모델’에 담는 것이다. 전통적인 방식에서는 요구사항 정의서, 아키텍처 다이어그램, 인터페이스 정의서, 테스트 계획서가 서로 다른 도구와 형식으로 작성되어 데이터의 불일치(Inconsistency)가 빈번히 발생했다. 반면 MBSE는 시스템의 구조(Structure), 동작(Behavior), 요구사항(Requirements), 파라미터(Parametrics)를 통합된 모델링 언어(주로 SysML)로 기술하여 중앙 저장소에 저장한다.

이 중앙 저장소는 프로젝트의 모든 이해관계자에게 ‘진실의 단일 공급원(Single Source of Truth, SSOT)’ 역할을 한다.5 설계자가 시스템의 특정 파라미터(예: 항공기 날개의 길이)를 수정하면, 이와 연관된 공기역학적 성능 계산식, 요구사항 충족 여부, 하위 부품의 규격 등이 모델 내의 추적성(Traceability) 링크를 통해 자동으로 업데이트되거나 경고를 발생시킨다.3 이는 정보의 일관성을 유지하고, 다학제 간(Multi-disciplinary) 협업에서 발생하는 오해를 원천적으로 차단한다.

graph TD
subgraph "MBSE 환경 (SSOT)"
CentralModel((("시스템 모델<br/>(SysML 중앙 저장소)")))

req["요구사항 (Requirements)<br/>- 기능/비기능 요구사항<br/>- 추적성 링크"]
struct["구조 (Structure)<br/>- BDD/IBD<br/>- 시스템 계층/인터페이스"]
behav["동작 (Behavior)<br/>- 상태 다이어그램<br/>- 액티비티/시퀀스"]
param["파라미터 (Parametrics)<br/>- 물성치/제약조건<br/>- 수식 (F=ma 등)"]

CentralModel <==> req
CentralModel <==> struct
CentralModel <==> behav
CentralModel <==> param
end

subgraph "외부 연결 및 분석"
Sim["시뮬레이션 도구<br/>(Matlab/Simulink 등)"]
Doc["문서 자동 생성<br/>(사양서/ICD)"]

param -.->|"데이터 바인딩"| Sim
CentralModel -.->|"퍼블리싱"| Doc
end

2.2 SysML: 디지털 엔지니어링의 링구아 프랑카(Lingua Franca)

UML(Unified Modeling Language)이 소프트웨어 공학의 표준이라면, SysML(Systems Modeling Language)은 이를 확장하여 하드웨어, 소프트웨어, 데이터, 인력, 절차를 포함한 전체 시스템을 기술하는 언어이다. SysML은 UML의 소프트웨어 중심적 요소를 배제하고 시스템 엔지니어링에 필수적인 다이어그램을 추가하여 MBSE의 기술적 기반을 제공한다.7

SysML의 주요 다이어그램과 역할:

  • 요구사항 다이어그램 (Requirement Diagram): 텍스트 기반의 요구사항을 모델 요소로 시각화하고, 다른 모델 요소(블록, 유스케이스 등)와의 관계(Satisfy, Verify, Refine, Trace)를 정의한다. 이를 통해 요구사항 추적성을 시각적으로 확보한다.8
  • 블록 정의 다이어그램 (BDD) 및 내부 블록 다이어그램 (IBD): 시스템의 계층적 구조와 인터페이스, 데이터 흐름을 정의한다.10
  • 파라메트릭 다이어그램 (Parametric Diagram): SysML의 가장 강력한 특징 중 하나로, 시스템 요소 간의 수학적 제약 조건을 정의한다. 예를 들어, 차량의 가속도 분석을 위해 F=ma (힘=질량 \times 가속도)와 같은 물리 방정식을 제약 블록(Constraint Block)으로 정의하고, 이를 시스템의 속성(질량, 엔진 출력 등)과 바인딩(Binding)한다.11 이는 단순한 그림이 아니라, 외부 시뮬레이션 도구(Matlab/Simulink, Mathematica 등)와 연동하여 엔지니어링 분석을 수행할 수 있는 실행 가능한 사양(Executable Specification)이 된다.13
mindmap
root(("SysML<br/>(시스템 모델링 언어)"))
Requirements_View["요구사항 다이어그램<br/>(Requirement Diagram)"]
::icon(fa fa-list)
("텍스트 시각화")
("추적성 (Traceability)")
("관계 정의 (Satisfy, Verify)")
Structure_View["구조 다이어그램<br/>(Structure)"]
::icon(fa fa-sitemap)
("블록 정의 (BDD)<br/>- 계층 구조")
("내부 블록 (IBD)<br/>- 데이터 흐름/인터페이스")
Parametrics_View["파라메트릭 다이어그램<br/>(Parametrics)"]
::icon(fa fa-calculator)
("수학적 제약 조건 (Constraint)")
("물리 방정식 (F=ma)")
("실행 가능한 사양 (Executable)")
Behavior_View["동작 다이어그램<br/>(Behavior)"]
::icon(fa fa-cogs)
("상태 전이 (State)")
("기능 실행 흐름 (Activity)")

graph LR
subgraph "시스템 컨텍스트 (Vehicle Context)"
direction TB

subgraph "시스템 속성 (Value Properties)"
Mass["질량 (m)<br/>val = 1500kg"]
Force["엔진 출력 (F)<br/>val = 3000N"]
Accel["가속도 (a)<br/>val = (계산됨)"]
end

subgraph "제약 블록 (Constraint Block)"
Eq["F = m * a"]

p_F["파라미터 F"]
p_m["파라미터 m"]
p_a["파라미터 a"]

Eq --- p_F
Eq --- p_m
Eq --- p_a
end
end

%% 바인딩 연결 (Binding Connectors)
Mass <==>|"Binding"| p_m
Force <==>|"Binding"| p_F
Accel <==>|"Binding"| p_a

%% 외부 도구 연동
Matlab["외부 솔버 (Matlab/Mathematica)"]
Eq -.->|"수식 전달 & 계산"| Matlab

2.3 디지털 스레드(Digital Thread)와 보잉의 다이아몬드 모델

MBSE는 단독으로 존재하지 않고 디지털 스레드를 통해 전체 수명 주기를 연결한다. 디지털 스레드는 개념 설계부터 폐기에 이르기까지 데이터가 단절 없이 흐르는 통신 프레임워크를 의미한다.15 보잉(Boeing)은 이를 ‘MBE 다이아몬드(MBE Diamond)’ 모델로 설명한다. 전통적인 V-모델이 물리적 시스템 개발에 초점을 맞췄다면, 보잉의 모델은 물리적 V-모델 위에 가상의 V-모델을 얹어 다이아몬드 형태를 구성한다. 이는 가상 세계(Digital)와 물리적 세계(Physical)의 대칭성을 강조하며, 디지털 스레드를 통해 두 세계가 실시간으로 데이터를 교환하고 상호 검증하는 체계를 나타낸다.17

디지털 스레드의 구축은 복잡한 시스템의 유지보수성을 획기적으로 향상시킨다. 예를 들어, 수백만 개의 부품으로 구성된 항공기의 경우, 특정 부품의 설계 데이터가 정비 매뉴얼 및 공급망 데이터와 디지털 스레드로 연결되어 있어, 설계 변경 시 정비 절차와 부품 수급 계획이 즉각적으로 조정될 수 있다.18

graph TD
subgraph "가상 세계 (Virtual World) - Virtual V"
VirtualDesign["가상 설계 (Virtual Design)<br/>- 모델링 & 시뮬레이션"]
VirtualVerify["가상 검증 (Virtual Validation)<br/>- 시뮬레이션 테스트"]
end

subgraph "연결 고리 (Connectivity)"
DT(("디지털 스레드<br/>(Digital Thread)"))
end

subgraph "물리적 세계 (Physical World) - Physical V"
PhysicalBuild["물리적 제작 (Physical Build)<br/>- 시제품/양산"]
PhysicalTest["물리적 테스트 (Physical Test)<br/>- 실제 환경 검증"]
end

%% 관계 설정 (다이아몬드 형태 구성)
VirtualDesign <--> DT
VirtualVerify <--> DT
DT <--> PhysicalBuild
DT <--> PhysicalTest

%% 흐름 (상호 보완)
VirtualVerify -.->|"사전 검증 피드백"| PhysicalTest
PhysicalTest -.->|"실측 데이터 보정"| VirtualDesign

3. V-모델의 진화: 시프트 레프트(Shift-Left) 전략의 경제학

3.1 전통적 V-모델의 구조적 모순

전통적인 시스템 엔지니어링의 V-모델은 왼쪽의 ‘분해 및 정의(Decomposition & Definition)’ 단계와 오른쪽의 ‘통합 및 검증(Integration & Verification)’ 단계로 명확히 구분된다. 이 모델은 논리적으로 타당해 보이지만, 실제 프로젝트에서는 치명적인 약점을 노출한다. 검증 활동이 물리적 시제품(Prototype)이 완성되는 프로젝트 후반부에 집중되기 때문이다. 만약 통합 테스트 단계에서 설계 결함이 발견되면, 이를 수정하기 위해 요구사항 정의 단계로 되돌아가야 하며, 이는 막대한 재설계 비용과 일정 지연을 유발한다.19

3.2 시프트 레프트(Shift-Left): 조기 검증을 통한 비용 절감

’시프트 레프트’는 V-모델의 오른쪽(검증) 활동을 왼쪽(초기 설계) 단계로 앞당기는 전략을 의미한다. 이는 “품질은 테스트 단계에서 만들어지는 것이 아니라, 설계 단계에서 내재화되어야 한다“는 철학에 기반한다.21 MBSE와 시뮬레이션 기술은 물리적 하드웨어 없이도 시스템의 기능을 검증할 수 있게 함으로써 시프트 레프트를 기술적으로 가능하게 한다.

IBM 시스템 과학 연구소(Systems Sciences Institute)와 여러 연구 기관의 데이터는 시프트 레프트의 경제적 가치를 명확히 보여준다. 결함 수정 비용은 개발 단계가 진행됨에 따라 지수적으로 증가한다.4

결함 발견 단계수정 비용 계수 (추정치)비고
요구사항/설계 (Design)1xMBSE 및 시뮬레이션을 통해 조기 발견 가능
구현/코딩 (Implementation)5x ~ 6.5x단위 테스트(Unit Test), 정적 분석 활용
통합 테스트 (Testing/Integration)15x전통적 V-모델에서 주로 결함이 발견되는 단계
배포/운영 (Maintenance/Production)100x리콜, 시스템 중단, 브랜드 가치 하락, 소송 비용 포함

이 데이터는 MBSE를 통한 초기 단계의 철저한 검증이 단순한 기술적 선택이 아니라, 프로젝트의 재무적 성공을 좌우하는 핵심 요소임을 시사한다. 시프트 레프트는 결함 예방(Prevention)을 결함 탐지(Detection)보다 우선순위에 둠으로써 전체 개발 주기를 단축하고 제품의 신뢰성을 높인다.21

xychart-beta
title "개발 단계별 결함 수정 비용 증가 (Cost of Change)"
x-axis ["설계 (Design)", "구현 (Coding)", "통합 (Integration)", "운영 (Operation)"]
y-axis "비용 계수 (배)" 0 --> 100
bar [1, 6.5, 15, 100]

3.3 W-모델과 애자일(Agile)의 결합

V-모델은 진화하여 ’W-모델’로 변모하고 있다. W-모델은 개발 프로세스(V의 왼쪽)와 테스트 프로세스(V의 오른쪽)가 동시에 병행됨을 나타낸다. 즉, 요구사항이 정의되는 즉시 그에 상응하는 테스트 케이스가 설계되고 가상 환경에서 검증된다.26 더 나아가, 소프트웨어 정의 자동차(SDV)와 같은 분야에서는 애자일(Agile) 방법론이 결합되어, 짧은 반복 주기(Sprint) 내에서 ’설계-구현-검증’이 지속적으로 순환하는 형태를 띤다.27 이때 MBSE 모델은 개발팀과 검증팀 간의 협업을 위한 공통 언어 역할을 하며, CI/CD(지속적 통합/배포) 파이프라인과 연동되어 자동화된 테스트를 수행한다.22

graph TD
subgraph "개발 프로세스 (Development)"
Req["요구사항 정의<br/>(Requirements)"]
Design["시스템 설계<br/>(Design)"]
Impl["구현/코딩<br/>(Implementation)"]
end

subgraph "테스트 프로세스 (Testing)"
TC_Req["테스트 계획/케이스 설계<br/>(Acceptance Test Design)"]
TC_Design["통합 테스트 설계<br/>(Integration Test Design)"]
Test_Exec["단위 테스트/실행<br/>(Unit Testing)"]
end

%% 병행 관계 (W-Model의 핵심: 개발 단계에서 테스트 준비가 동시에 일어남)
Req <==>|"동시 수행 & 검증"| TC_Req
Design <==>|"동시 수행 & 검증"| TC_Design
Impl <==>|"CI/CD 연동"| Test_Exec

%% 시간 흐름
Req --> Design --> Impl
TC_Req --> TC_Design --> Test_Exec

4. 가상 검증(Virtual Validation)과 X-in-the-Loop

시프트 레프트를 실현하는 핵심 수단은 가상 검증이다. 물리적 시제품이 없는 상태에서 시스템을 검증하기 위해 다양한 레벨의 시뮬레이션 기법(X-in-the-Loop)이 활용된다.

4.1 가상 검증의 계층 구조

  1. MIL (Model-in-the-Loop): 가장 초기 단계의 검증으로, 제어 로직과 플랜트(Plant) 모델을 시뮬레이션 환경(예: Simulink)에서 연결하여 알고리즘의 유효성을 검증한다. 하드웨어나 코딩 제약 없이 순수한 기능적 요구사항 충족 여부를 확인한다.29
  2. SIL (Software-in-the-Loop): 모델로부터 생성된 소스 코드(주로 C/C++)를 PC 환경에서 컴파일하여 가상 시뮬레이터와 연동한다. 이 단계에서는 자동 생성된 코드의 논리적 오류, 데이터 타입 오버플로우, 0으로 나누기 등의 소프트웨어적 결함을 검증한다.31
  3. PIL (Processor-in-the-Loop): 생성된 코드를 실제 타겟 프로세서(또는 그와 유사한 에뮬레이터)에 다운로드하여 실행하되, 플랜트 모델은 여전히 PC에서 실행된다. 프로세서의 아키텍처 특성(메모리 정렬, 실행 시간 등)이 반영된 검증이 가능하다.31
  4. HIL (Hardware-in-the-Loop): 실제 ECU(Electronic Control Unit) 하드웨어를 실시간 시뮬레이터(Real-time Simulator)와 연결하여 테스트한다. 시뮬레이터는 센서 신호를 모사하여 ECU에 입력하고, ECU의 제어 신호를 받아 가상 차량/항공기의 동작을 계산한다.32
flowchart LR
subgraph "가상 검증 프로세스 (Virtual Validation)"
direction TB

MIL["MIL (Model-in-the-Loop)<br/>- 모델 vs 모델<br/>- 알고리즘 논리 검증"]
SIL["SIL (Software-in-the-Loop)<br/>- 소스코드(C/C++) vs 모델<br/>- 코드 논리/오버플로우 검증"]
PIL["PIL (Processor-in-the-Loop)<br/>- 타겟 프로세서 vs 모델(PC)<br/>- 아키텍처 특성 반영"]
HIL["HIL (Hardware-in-the-Loop)<br/>- 실제 ECU vs 실시간 시뮬레이터<br/>- 센서/액추에이터 모사"]

MIL ==>|"코드 생성"| SIL
SIL ==>|"크로스 컴파일/다운로드"| PIL
PIL ==>|"하드웨어 통합"| HIL
end

style MIL fill:#e1f5fe,stroke:#01579b
style SIL fill:#b3e5fc,stroke:#0277bd
style PIL fill:#81d4fa,stroke:#0288d1
style HIL fill:#4fc3f7,stroke:#039be5

4.2 HIL 시뮬레이션의 ROI와 산업별 사례

HIL은 물리적 테스트를 대체하거나 보완함으로써 막대한 ROI(투자 대비 수익)를 창출한다.

  • 항공우주 분야: NASA의 HILSIM 시설이나 V-22 오스프리(Osprey) 개발 사례에서 볼 수 있듯이, 실제 비행 테스트는 위험하고 비용이 많이 든다. HIL을 통해 비행 중 발생할 수 있는 극한의 상황(VRS 등)이나 고장 모드를 지상에서 안전하게 재현하고 검증할 수 있다.33
  • 자동차 분야: 자율주행 시스템 검증을 위해서는 수십억 킬로미터의 주행 테스트가 필요하다. 이를 물리적으로 수행하는 것은 불가능하므로, 가상 환경에서 수만 가지의 시나리오를 시뮬레이션하는 것이 필수적이다. 가상 검증은 물리적 프로토타입 제작 비용을 절감하고, 개발 기간을 획기적으로 단축시킨다.20 포드(Ford)와 미 육군 TARDEC의 전문가들은 가상 테스트가 지배적이지만, 센서 퓨전 등의 복잡성으로 인해 물리적 테스트가 완전히 사라지지는 않을 것이라고 지적하며 상호 보완적인 접근을 강조한다.37

4.3 디지털 트윈: 가상 검증의 정점

디지털 트윈은 시뮬레이션 모델을 실시간 운영 데이터와 연결하여 가상 검증의 범위를 운영 단계까지 확장한다.

  • 양방향 동기화: 물리적 시스템(Physical Twin)의 센서 데이터가 디지털 트윈으로 전송되어 모델을 현실과 동기화(Calibration)하고, 디지털 트윈의 시뮬레이션 결과(최적화된 파라미터 등)가 다시 물리적 시스템에 반영된다.38
  • 의료 분야 사례: 환자의 혈류나 두개골 진동 데이터를 디지털 트윈 모델에 입력하여 경동맥 협착증의 심각도를 진단하거나, 약물 반응을 시뮬레이션하여 개인 맞춤형 치료 계획을 수립한다.40
  • 항공우주 사례: NASA는 오리온(Orion) 우주선 프로젝트에서 디지털 트윈을 활용하여 복잡한 시스템의 이상 징후를 감지하고 미션 성공 확률을 높이는 데 기여했다.42
graph TB
subgraph "물리적 트윈 (Physical Twin)"
RealSystem["실제 시스템<br/>(항공기/환자/공장)"]
Sensors["IoT 센서/데이터 수집"]
Actuators["제어 장치/실행"]
end

subgraph "디지털 트윈 (Digital Twin)"
VirtualModel["고정밀 시뮬레이션 모델"]
Analytics["AI/머신러닝 분석"]
end

%% 데이터 흐름
RealSystem --> Sensors
Sensors ==>|"실시간 운영 데이터<br/>(동기화)"| VirtualModel

VirtualModel --> Analytics
Analytics ==>|"최적화 파라미터/예측<br/>(피드백)"| Actuators
Actuators --> RealSystem

5. 규제 프레임워크와 MBSE: DO-178C와 DO-331 심층 분석

안전 필수 시스템, 특히 항공우주 분야에서는 기술적 혁신만큼이나 인증(Certification) 획득이 중요하다. 2011년 발표된 **DO-178C (Software Considerations in Airborne Systems and Equipment Certification)**는 MBSE를 공식적인 개발 방법론으로 수용하기 위해 보충 문서인 **DO-331 (Model-Based Development and Verification)**을 제정했다. 이는 규제 당국이 MBSE의 안전성을 인정한 중요한 전환점이다.43

graph TD
subgraph "DO-331 개발 흐름"
HLR["상위 레벨 요구사항 (HLR)"]
SpecModel["사양 모델 (Specification Model)<br/>- 기능 정의"]
LLR["하위 레벨 요구사항 (LLR)"]
DesignModel["설계 모델 (Design Model)<br/>- 아키텍처/데이터 흐름"]
AutoCode["자동 생성 코드 (Source Code)"]
EOC["실행 객체 코드 (Executable Object Code)"]

HLR --> SpecModel
SpecModel --> LLR
LLR --> DesignModel
DesignModel -->|"자격 갖춘 도구 (Qualified Tool)"| AutoCode
AutoCode -->|"컴파일"| EOC
end

subgraph "검증 활동 (Verification)"
ModelSim["모델 시뮬레이션<br/>(모델 커버리지 확인)"]
StrucTest["타겟 하드웨어 테스트<br/>(구조적 커버리지 확인)"]

SpecModel -.->|"검증"| ModelSim
DesignModel -.->|"검증"| ModelSim
EOC -.->|"검증"| StrucTest
end

style AutoCode fill:#ffcc80,stroke:#e65100
style ModelSim fill:#fff9c4,stroke:#fbc02d

5.1 DO-331의 핵심 개념: 사양 모델 vs 설계 모델

DO-331은 모델의 용도와 역할에 따라 두 가지로 엄격히 구분한다.45

  1. 사양 모델 (Specification Model): 상위 레벨 요구사항(High-Level Requirements, HLR)을 표현한다. 소스 코드를 생성하지 않으며, 시스템의 기능을 정의하는 데 중점을 둔다.
  2. 설계 모델 (Design Model): 하위 레벨 요구사항(Low-Level Requirements, LLR)을 표현하며, 이로부터 소스 코드가 자동 생성(Auto-Code Generation)되거나 수동으로 작성된다. 설계 모델은 소프트웨어 아키텍처와 데이터 흐름을 구체적으로 담고 있어야 한다.

5.2 자동 코드 생성과 검증 목표 (Objectives)

DO-331은 모델 기반 개발 시 준수해야 할 추가적인 목표(Objectives)를 정의한다. 특히 MB.A-3 (소프트웨어 요구사항 프로세스 검증), MB.A-4 (소프트웨어 설계 프로세스 검증), MB.A-5 (소프트웨어 코딩 및 통합 프로세스 검증) 테이블에 명시된 목표들이 중요하다.46

  • 자동 코드 생성의 검증: 모델에서 코드를 자동으로 생성하는 경우, 해당 코드 생성 도구(Tool)가 자격(Qualification)을 갖추었는지가 중요하다. DO-330에 따라 자격을 갖춘 도구(Qualified Tool)를 사용하면, 생성된 코드에 대한 일부 검증 활동(예: 코드 리뷰, 코딩 규칙 준수 확인)을 생략할 수 있어 개발 효율성이 극대화된다.47 그러나 자격이 없는 도구를 사용할 경우, 자동 생성된 코드라 할지라도 수동 코드와 동일한 수준의 검증을 거쳐야 한다.48

5.3 커버리지 논쟁: 모델 커버리지 vs 구조적 커버리지

DO-331 도입 당시 가장 뜨거운 논쟁 주제는 “모델 시뮬레이션만으로 코드 레벨의 테스트를 대체할 수 있는가?“였다. 결론적으로 DO-331은 **모델 커버리지(Model Coverage)**와 **구조적 커버리지(Structural Coverage)**를 구분하여 접근한다.49

  • 모델 커버리지: 시뮬레이션을 통해 모델의 모든 블록, 상태 전이, 조건이 실행되었는지를 확인한다. 이는 모델 내의 ’의도하지 않은 기능(Unintended Functionality)’을 발견하는 데 필수적이다.
  • 구조적 커버리지: 실제 타겟 하드웨어에서 실행되는 실행 객체 코드(Executable Object Code, EOC)가 얼마나 테스트되었는지를 측정한다(예: MC/DC).
  • 상호 보완성: DO-331은 모델 커버리지만으로 구조적 커버리지 목표를 완전히 달성했다고 인정하지 않는다(특히 Level A 소프트웨어의 경우). 컴파일러나 코드 생성기가 예측 불가능한 코드를 생성할 수 있기 때문이다. 따라서 모델 시뮬레이션을 통해 조기에 검증을 수행하되, 최종적으로는 타겟 하드웨어에서의 테스트를 통해 구조적 커버리지를 입증해야 한다.44 모델 커버리지는 구조적 커버리지 달성을 돕는 보조적이지만 강력한 수단으로 인정받는다.
graph TD
subgraph "완전한 인증 (Complete Certification)"
Goal(("안전성 입증<br/>(Safety Assurance)"))
end

subgraph "1단계: 모델 커버리지 (Model Coverage)"
Sim["모델 시뮬레이션"]
ModelCovCheck{"모든 경로/조건 실행됨?"}
Detect1["'의도하지 않은 기능'<br/>(Unintended Functionality) 발견"]
end

subgraph "2단계: 구조적 커버리지 (Structural Coverage)"
TargetTest["타겟 하드웨어 실행"]
CodeCovCheck{"실행 객체 코드(EOC)<br/>모두 실행됨?"}
Detect2["컴파일러/코드 생성기<br/>오류 발견"]
end

%% 흐름
Sim --> ModelCovCheck
ModelCovCheck -- "No" --> Detect1
ModelCovCheck -- "Yes (조기 검증 완료)" --> TargetTest

TargetTest --> CodeCovCheck
CodeCovCheck -- "No" --> Detect2
CodeCovCheck -- "Yes (최종 검증 완료)" --> Goal

%% 관계 강조
Detect1 -.->|"설계 수정"| Sim
Detect2 -.->|"코드/설계 수정"| TargetTest

6. MBSE와 AI의 융합: 생성형 AI와 미래 전망

flowchart TB
InputDocs["비정형 문서<br/>(RFP, 제안요청서, 규제)"]

subgraph "AI 기반 모델 생성 (Generative AI)"
LLM["대규모 언어 모델 (LLM)<br/>(NLP/SysTemp)"]
SysMLText["SysML v2<br/>(텍스트 표기법)"]
end

subgraph "지능형 분석 (Intelligent Analysis)"
SimEngine["시뮬레이션 엔진"]
AI_Inspector["AI 결함 탐지기<br/>(패턴 인식/Edge Case 발견)"]
end

OutputModel["검증된 시스템 모델"]

%% 흐름 연결
InputDocs -->|"텍스트 추출"| LLM
LLM -->|"코드 생성"| SysMLText
SysMLText -->|"실행"| SimEngine
SimEngine -->|"결과 데이터"| AI_Inspector
AI_Inspector -->|"피드백/수정"| LLM
AI_Inspector -->|"승인"| OutputModel

6.1 생성형 AI(GenAI)를 통한 모델링 자동화

MBSE 도입의 높은 진입 장벽 중 하나는 SysML과 같은 정형 언어를 배우고 모델을 구축하는 데 드는 시간과 노력이다. 최근 대규모 언어 모델(LLM)과 생성형 AI 기술은 이러한 장벽을 허물고 있다.51

  • 요구사항 분석 및 모델 생성: 자연어 처리(NLP) 기술을 활용하여 수천 페이지의 비정형 RFP(제안요청서) 문서에서 요구사항을 자동으로 추출하고, 이를 기반으로 SysML 요구사항 다이어그램이나 초기 아키텍처 모델을 생성하는 연구가 진행되고 있다. SysTemp와 같은 프레임워크는 LLM 에이전트가 SysML v2 코드를 생성하고, 구문 분석 에이전트가 이를 검증하는 반복 과정을 통해 정확한 모델을 구축한다.53
  • SysML v2와 텍스트 기반 모델링: SysML v2는 그래픽뿐만 아니라 텍스트 표기법을 공식적으로 지원한다. 이는 LLM이 코드를 생성하듯 시스템 모델을 텍스트로 생성하기 쉽게 만들어, AI와 MBSE의 결합을 가속화하고 있다.51

6.2 AI 기반 가상 검증

AI는 시뮬레이션 데이터를 분석하는 데에도 활용된다. 머신러닝 알고리즘은 수만 번의 몬테카를로 시뮬레이션 결과에서 인간 엔지니어가 놓치기 쉬운 결함 패턴이나 경계 조건(Edge Case)을 식별한다. 이는 검증의 효율성을 높이고, 시스템의 안전성을 강화하는 데 기여한다.55

7. 구현 과제 및 극복 방안

graph LR
subgraph "1: 직면한 장벽 (Barriers)"
direction TB
B_Culture["문화적 저항 (Cultural Resistance)<br/>- 기존 방식 고수"]
B_Skill["기술 격차 (Skills Gap)<br/>- 전문 인력 부족"]
B_Tool["데이터 사일로 (Data Silos)<br/>- 도구 상호운용성 부족"]
end

subgraph "2: 극복 전략 (Solutions)"
direction TB
S_Project["파일럿 프로젝트 (Quick Win)<br/>- 성공 경험 축적 & 경영진 의지"]
S_Edu["단계적 교육 프로그램<br/>(Training & Mentoring)"]
S_Std["개방형 표준 도입<br/>(OSLC, FMI, FMP)"]
end

subgraph "3: 최종 목표 (Goal)"
direction TB
Mindset["데이터 중심 사고<br/>(Data-Centric Mindset)"]
Success(("성공적인<br/>디지털 트랜스포메이션"))
end

%% 문제와 해결책 연결
B_Culture ==>|"극복"| S_Project
B_Skill ==>|"해소"| S_Edu
B_Tool ==>|"해결"| S_Std

%% 결과로 연결
S_Project --> Mindset
S_Edu --> Mindset
S_Std --> Success
Mindset --> Success

%% 스타일링
style B_Culture fill:#ffcdd2,stroke:#b71c1c,stroke-width:2px
style B_Skill fill:#ffcdd2,stroke:#b71c1c,stroke-width:2px
style B_Tool fill:#ffcdd2,stroke:#b71c1c,stroke-width:2px

style S_Project fill:#fff9c4,stroke:#fbc02d,stroke-width:2px
style S_Edu fill:#fff9c4,stroke:#fbc02d,stroke-width:2px
style S_Std fill:#fff9c4,stroke:#fbc02d,stroke-width:2px

style Mindset fill:#c8e6c9,stroke:#2e7d32
style Success fill:#b2ebf2,stroke:#006064,stroke-width:4px

7.1 문화적 저항과 기술 격차

MBSE 도입 실패의 주된 원인은 기술적 결함보다는 조직의 문화적 저항에 있다. 문서 기반 업무 방식에 익숙한 베테랑 엔지니어들은 새로운 도구와 프로세스에 거부감을 느낄 수 있다. 또한, 모델링 언어와 도구를 능숙하게 다룰 수 있는 전문 인력의 부족은 심각한 문제이다.57

  • 해결책: 경영진의 강력한 의지와 함께, 단계적인 교육 프로그램과 파일럿 프로젝트를 통한 성공 경험(Quick Win) 축적이 필요하다.

7.2 도구 상호운용성(Interoperability) 및 데이터 사일로

다양한 벤더(Vendor)의 MBSE 도구, CAD, CAE, PLM 솔루션 간의 데이터 호환성 부족은 디지털 스레드의 단절을 초래한다. ‘역 돌출부(Reverse Salient)’ 현상처럼, 특정 도구의 기술적 낙후가 전체 시스템의 성능을 저해할 수 있다.59

  • 해결책: OSLC(Open Services for Lifecycle Collaboration)와 같은 개방형 표준을 채택하고, FMI(Functional Mock-up Interface)를 통한 공동 시뮬레이션(Co-simulation) 환경을 구축하여 도구 간의 장벽을 허물어야 한다.1
graph TB
subgraph "통합 엔지니어링 환경 (Digital Thread Backbone)"
Standard_Layer["개방형 표준 인터페이스"]

direction BT
MBSE_Tool["MBSE 도구<br/>(시스템 아키텍처)"]
CAD["CAD 도구<br/>(기구 설계)"]
CAE["CAE/Simulink<br/>(해석/알고리즘)"]
PLM["PLM 시스템<br/>(데이터 관리)"]

%% 연결 표준
MBSE_Tool <-->|"OSLC<br/>(데이터 연결)"| PLM
CAE <-->|"FMI<br/>(공동 시뮬레이션)"| MBSE_Tool
CAD -.->|"형상 정보"| CAE
end

subgraph "해결된 문제"
Silos["데이터 사일로 (Data Silos) 제거"]
ReverseSalient["역 돌출부 (Reverse Salient) 극복"]
end

Standard_Layer === Silos

style Standard_Layer fill:#e0f7fa,stroke:#006064,stroke-width:2px
style MBSE_Tool fill:#f3e5f5,stroke:#7b1fa2
style CAE fill:#e1f5fe,stroke:#0288d1

8. 결론

MBSE와 디지털 트랜스포메이션은 단순한 유행이 아니라, 복잡성의 시대를 생존하기 위한 엔지니어링의 필연적인 진화이다. V-모델은 시프트 레프트 전략을 통해 개발 초기 단계에서의 가상 검증을 강화하는 방향으로 재편되었으며, 이는 천문학적인 결함 수정 비용을 절감하고 제품 출시 기간을 단축하는 핵심 동력이 되었다.

항공우주의 DO-178C/DO-331과 같은 표준은 이러한 변화를 제도적으로 뒷받침하며, 모델 기반 개발이 안전 필수 시스템에서도 신뢰할 수 있는 방법론임을 입증했다. 더 나아가 AI와 결합된 MBSE는 모델링의 자동화와 지능형 검증을 통해 엔지니어의 역할을 단순 반복 작업에서 창의적인 설계와 의사결정으로 격상시키고 있다.

기업과 조직은 도구의 도입을 넘어, 데이터 중심의 사고방식(Data-Centric Mindset)으로 조직 문화를 혁신하고, 디지털 스레드를 통해 전체 가치 사슬을 연결하는 통합적인 전략을 수립해야 한다. 2025년 이후의 엔지니어링 경쟁력은 누가 더 빠르고 정확하게 가상 세계에서 현실을 검증해내느냐에 달려 있다.

9. 참고 자료

  1. MBSE Trends: The Future of Model-Based Systems Engineering - SPEC Innovations, https://specinnovations.com/blog/mbse-trends
  2. Embracing the Evolution: The Rise of Model-Based Systems Engineering - STC, https://stc.arcfield.com/post/embracing-the-evolution-the-rise-of-model-based-systems-engineering
  3. An Introduction to Model-Based Systems Engineering (MBSE), https://www.sei.cmu.edu/blog/introduction-model-based-systems-engineering-mbse/
  4. The Hidden $2.4 Trillion Crisis: Why Software Quality Can’t Wait - DEV Community, https://dev.to/esha_suchana_3514f571649c/the-hidden-24-trillion-crisis-why-software-quality-cant-wait-57ei
  5. What is Model-Based Systems Engineering (MBSE)? - Ansys, https://www.ansys.com/blog/model-based-systems-engineering-explained
  6. Understanding 10 key principles of model-based system engineering (MBSE) - Starion, https://www.stariongroup.eu/understanding-10-key-principles-of-model-based-system-engineering-mbse/
  7. MBSE and SysML - Visual Paradigm, https://www.visual-paradigm.com/guide/sysml/mbse-and-sysml/
  8. SysML: Establishing Traceability using Matrix and ETL Table - Visual Paradigm, https://www.visual-paradigm.com/guide/sysml/establish-traceability-using-matrix-and-etl-table/
  9. Overview of traceability matrices and tables (SysML diagram) - PTC Support Portal, https://support.ptc.com/help/modeler/r10.2/en/Modeler/sysml/SysML_Overview_of_traceability_relationships_diagrams_matrices_and_tables.html
  10. OMG SysML™ Requirements Traceability, https://www.omgwiki.org/OMGSysML/lib/exe/fetch.php?media=sysml-roadmap:omg_sysml_requirements_traceabilityptc-07-03-09.pdf
  11. SysML: Expressing Model Element Constraints with Parametric Diagrams - Visual Paradigm, https://www.visual-paradigm.com/guide/sysml/express-model-constraints-with-parametric-diagram/
  12. Modeling with SysML, https://www.jhuapl.edu/sites/default/files/2023-03/ModelingwithSysMLTutorial.pdf
  13. System Analysis using SysML Parametrics - OpenModelica, https://openmodelica.org/images/docs/modprod2011-tutorial/modprod2011-tutorial4-Chris-Paredis-SysML-Parametrics.pdf
  14. SysML - Building A Parametric Diagram from Scratch - YouTube, https://www.youtube.com/watch?v=6l7Vy4nR9E4
  15. Mastering the Complexity of Systems with Digital Engineering - SodiusWillert, https://www.sodiuswillert.com/en/blog/mastering-the-complexity-of-systems-with-digital-engineering
  16. Digital thread: redefining digital transformation - Siemens Digital Industries Software, https://www.sw.siemens.com/en-US/digital-thread/
  17. Model Based Engineering (MBE) Supplier Integration - Boeing Suppliers, https://www.boeingsuppliers.com/become/modelbasedengineering
  18. Digital Threading, Model-Based Systems Engineering, and AI | Accuris, https://accuristech.com/a-conversation-on-digital-threading-model-based-systems-engineering-and-the-critical-role-of-ai/
  19. Four Types of Shift Left Testing - Software Engineering Institute, https://www.sei.cmu.edu/blog/four-types-of-shift-left-testing/
  20. Shifting Left: The Evolution of Automotive Validation Test - NI - National Instruments, https://www.ni.com/en/solutions/transportation/adas-and-autonomous-driving-testing/adas-and-autonomous-driving-validation/shifting-left-the-evolution-of-automotive-validation-test.html
  21. Shift-Left – Testing, Approach, & Strategy - New Relic, https://newrelic.com/blog/best-practices/shift-left-strategy-the-key-to-faster-releases-and-fewer-defects
  22. Shift Left Testing in Software Development, https://www.bmc.com/blogs/what-is-shift-left-shift-left-testing-explained/
  23. True Cost of Software Defects: Customer Churn, https://www.perforce.com/blog/pdx/cost-of-software-defects
  24. The Hidden Cost Of Bad Software Practices: Why Talent And Engineering Standards Matter, https://www.forbes.com/councils/forbestechcouncil/2025/03/28/the-hidden-cost-of-bad-software-practices-why-talent-and-engineering-standards-matter/
  25. Shift Left Testing: Turn Quality Into a Growth Engine - Abstracta, https://abstracta.us/blog/devops/shift-left-testing/
  26. Model-Based Systems Engineering for Digital Twin System Development Applied to an Aircraft Seat Test Bench - IEEE Xplore, https://ieeexplore.ieee.org/iel8/6287639/10820123/10971934.pdf
  27. V Model in System Engineering - Visure Solutions, https://visuresolutions.com/alm-guide/v-model-systems-engineering/
  28. Shift-Left Testing: Types, Benefits, and Best Practices - Virtuoso QA, https://www.virtuosoqa.com/post/shift-left-testing-early-with-the-sdlc
  29. MATLAB and Simulink for Aerospace Certification Standards Compliance - MathWorks, https://www.mathworks.com/solutions/aerospace-defense/certification-standards.html
  30. Optimized Model- Based Verification Process to Comply with DO-178C DO-331 Objectives, https://www.ansys.com/resource-center/white-paper/optimized-model-based-verification-process-to-comply-with-do-178c-do-331-objectives
  31. A Virtual Testing Framework for Real-Time Validation of Automotive Software Systems Based on Hardware in the Loop and Fault Injection - PMC - NIH, https://pmc.ncbi.nlm.nih.gov/articles/PMC11207294/
  32. The ‘digital twin’ in hardware-in-the-loop (HIL) simulation: a conceptual primer - OPAL-RT, https://www.opal-rt.com/blog/the-digital-twin-in-hardware-in-the-loop-hil-simulation/
  33. A Hardware-In-The-Loop Simulator for Software Development for a Mars Airplane, https://ntrs.nasa.gov/api/citations/20070030310/downloads/20070030310.pdf
  34. Enhancing predictive maintenance (PdM) with hardware in the loop (HIL) systems - Fiix, https://fiixsoftware.com/blog/hardware-in-the-loop/
  35. Data-Driven Aerospace Engineering: Reframing the Industry with Machine Learning | AIAA Journal, https://arc.aiaa.org/doi/10.2514/1.J060131
  36. Whitepaper: Virtual Validation in the Automotive Industry • in-tech.com, https://in-tech.com/en/articles/whitepaper-virtual-validation-in-the-automotive-industry
  37. Virtual Validation on the Rise, but Physical Testing Remains Crucial, https://www.mobilityengineeringtech.com/component/content/article/43528-sae-ma-02839
  38. Chapter: 2 The Digital Twin Landscape - National Academies of Sciences, Engineering, and Medicine, https://www.nationalacademies.org/read/26894/chapter/4
  39. A Conceptual Model-based Systems Engineering (MBSE) approach to develop Digital Twins - UTRGV, https://www.utrgv.edu/mecis/_files/documents/a_conceptual_model-based_systems_engineering_mbse_approach_to_develop_digital_twins.pdf
  40. Digital twin in healthcare: Recent updates and challenges - PMC - NIH, https://pmc.ncbi.nlm.nih.gov/articles/PMC9830576/
  41. Digital twins for health: a scoping review - PMC - PubMed Central, https://pmc.ncbi.nlm.nih.gov/articles/PMC10960047/
  42. Orion SysML Model, Digital Twin, and Lessons Learned for Artemis I - NASA Technical Reports Server, https://ntrs.nasa.gov/api/citations/20220017217/downloads/Orion%20Digital%20Twin%20v9.pdf
  43. DO-331: Model-Based Development and Verification Supplement to DO-178C and DO-278A - Visure Solutions, https://visuresolutions.com/aerospace-and-defense/do-331/
  44. DO-331/ED-216 Model-Based Development and Verification Supplement: When, where, and how it applies - LDRA, https://ldra.com/do-331/
  45. DO-331 Model Based Development and Verification Supplement to DO- 178C and DO-278A - APT Research, https://www.apt-research.com/wp-content/uploads/2017/05/MBSESSS_DO-331_Alford_Hendrix.pdf
  46. DO 331 Objectives List | Must Know - TheCloudStrap, https://thecloudstrap.com/do-331-objectives-list/
  47. DO-331 Explained | ConsuNova, Inc., https://consunova.com/do-331-explained/
  48. Testing auto-generated code for safety-critical systems - LDRA, https://ldra.com/testing-auto-generated-code-for-safety-critical-systems/
  49. RTCA DO 331 Model-Based Development and Verification in aerospace - Heicon Ulm, https://heicon-ulm.de/en/rtca-do331-model-based-development-and-verification-in-aerospace/
  50. An introduction to DO-178C | Ansys Knowledge, https://innovationspace.ansys.com/knowledge/forums/topic/an-introduction-to-do-178c/
  51. Leveraging Generative AI to Build, Modify, and Query MBSE Models - DAIR - Acquisition Research Program, https://dair.nps.edu/bitstream/123456789/5237/1/SYM-AM-24-138.pdf
  52. Generative Artificial Intelligence: The Future of Model Based Systems Engineering, https://sercuarc.org/wp-content/uploads/2025/06/0840_Thomas-Heckwolf_i3_AI4SE_GenerativeAI_11Oct2023.pdf
  53. Using LLMs to Accelerate SysML Model Requirements Gap Analysis - Systems Engineering Research Center, https://sercuarc.org/wp-content/uploads/2025/09/Hetherington_Using_LLMs_to_Accelerate_SysML_Model_Requirements_Gap_Analysis.pdf
  54. SysTemp: A Multi-Agent System for Template-Based Generation of SysML v2 - arXiv, https://arxiv.org/html/2506.21608v1
  55. MBSE 2.0: Toward More Integrated, Comprehensive, and Intelligent MBSE - MDPI, https://www.mdpi.com/2079-8954/13/7/584
  56. Digital Twin Incorporating Deep Learning and MBSE for Adaptive Manufacturing of Aerospace Parts - MDPI, https://www.mdpi.com/2227-9717/13/5/1376
  57. What is Shift-Left Testing - A Comprehensive Guide - HeadSpin, https://www.headspin.io/blog/essence-of-shift-left-testing-in-organizations
  58. Shift-Left validation for software-defined vehicles - HCLTech, https://www.hcltech.com/trends-and-insights/software-defined-vehicles-new-era-validation-shift-left-strategies
  59. Seamless Digital Engineering: A Grand Challenge Driven by Needs - arXiv, https://arxiv.org/html/2401.02059v1
  60. Barriers for Adopting FMI-based Co-Simulation in Industrial MBSE Processes - Dynatrace, https://www.dynatrace.com/research/publications/barriers-for-adopting-fmi-based-co-simulation-in-industrial-mbse-processes/